I have a folder of half-built products, and they all failed in the same direction. Not one of them was too small. Every single one was too big on the day I started, and I spent the following months quietly discovering that.
So now I open every project with the same question, and I write the answer down before I write any code: what is the smallest version of this that a real person would pay for or come back to?
The answer is always smaller than it feels
When I built Cutlass, the first honest answer was: a command that takes a folder and puts it on the internet. No config file. No plugins. No accounts. One command, one folder, one URL.
That took eleven days. The version I had been sketching for a month — the one with a dashboard, a plugin system and a team plan — would have taken most of a year, and I would have learned nothing until the end of it.
Cutting is not the same as compromising
The trick is to cut whole limbs rather than trim every one of them. A product with six half-features feels broken. A product with one complete feature feels deliberate, and people forgive an enormous amount of missing surface area as long as the part that exists is finished.
- Cut every setting. Pick the default you would have recommended anyway.
- Cut the account system. Ask who genuinely needs to be logged in on day one.
- Cut the second use case. It is almost never the one that pays.
If the smallest version embarrasses you, it is probably the right size. Embarrassment fades in a week. An unfinished project follows you around for years.
What to do with everything you cut
Write it down and then genuinely forget it. I keep one plain text file per project called later.md, and I have never once shipped something from it in the first six months. Which is the point: it was never the thing standing between me and a working product.
The list is not a roadmap. It is a place to put ideas so they stop taking up room.